Wait out the iOS retry backoff when the system refuses a delayed task - #80

What could go wrong

On iOS, a retry's backoff exists only as the begin date of a background task: the library creates the next attempt right away and lets nsurlsessiond hold it until the date. If the daemon refuses the app's connection, that task fails immediately with NSURLErrorDomain -1, before its begin date and without sending anything. The library counted that as a transient failure and created the next delayed task at once, which failed the same way.

That loop ran at 300–600 attempts a second, each writing the entry and opening a new XPC connection. The app sat at about 200% CPU and grew to gigabytes of memory. We hit it on two simulators running diana's CI dev builds, which had no entitlements, so the daemon logged "does not have a bundle ID, rejecting connection" for every session. That build is fixed in openspacelabs/diana#9825. The library should still not spin when the daemon says no.

What this PR does

• A refused delayed task isn't an attempt. A delayed task that ends before its begin date, with no response and no bytes sent, never reached the daemon. It emits no event and keeps its ordinal and request id. The app waits out the rest of the delay itself, then issues the attempt again (advanceAttempt: false). All three conditions are needed, so a clock change during the wait can't turn a real failure into this. The error code isn't checked, because -1 also comes with real failures.
• Chunked parts get the same treatment. A refused part task keeps its begin date and refills once the date passes. Unlike a simple request, the refilled part still takes a new ordinal, as every part task does.
• A floor as a backstop, simple requests only. A retry never starts within baseMs of the previous attempt's start. One that ended before its own start gets no task for baseMs. The floor lives in memory only.
• TaskCompletion carries bytesSent (from countOfBytesSent) so the completion path can tell.

Android doesn't have this flaw: it waits out the backoff itself before making the request.

Review notes

• System cancels change slightly. If iOS cancels a delayed task before its begin date with nothing sent, the library now waits out the delay under the same ordinal, instead of minting a new attempt with a fresh backoff. It never ran, so that seems right.
• Four existing tests now advance the fake clock before completing a delayed task. They delivered a server response before the task's begin date, which the real daemon can't do, and that tripped the floor.
• Conflicts with Skip unchanged setWifiOnly writes and put the cause in E_STORAGE #69 and Do not reject settings calls when the settings file cannot be saved #72 in QueueCoordinator+Outcomes.swift. It's small: one added line, attemptStarts[id] = nil, next to code Skip unchanged setWifiOnly writes and put the cause in E_STORAGE #69 rewrites. Build iOS part tasks in slices so the next mutate() does not wait #70 and Release v9 bytes no row owns, and reuse the v9 blob on a replace #65 merge cleanly with this branch and pass the suite (293 and 272 tests).

How it was tested

• swift test in ios/: 263 tests, 0 failures, 5 new. They cover every task refused for 10 s of fake time (bounded attempts, no tight loop), one refused task keeping its ordinal and X-Request-Id, a task failing after its begin date still counting, a task that sent bytes or got a 503 early still counting, and a refused chunked part. With the fix disabled the new tests fail.
• In diana on an iPhone 15 simulator, with this branch in node_modules and the app built with CODE_SIGNING_ALLOWED=NO, so the daemon refuses it:
  • A stuck upload went from about 5,500 attempts per 30 s to 1 attempt per backoff.
  • Two new uploads backed off with growing gaps (about 14 s, 32 s, 74 s).
  • CPU stayed under 2%.
  • With v11.1.0 the same build spun at 199% CPU.
• No JS changed, so yarn lint:ci, typecheck and test weren't run.

🤖 Generated with Claude Code